Skip to content

Conversation

asgeija
Copy link
Member

@asgeija asgeija commented Oct 8, 2026

Defines the Sighting type, a query for one sighting by id and a query for a list with search, filter, sort and cursor pagination. Documents the pagination choice in the README.

Defines the Sighting type, a query for one sighting by id and a
query for a list with search, filter, sort and cursor pagination.
Documents the pagination choice in the README.
@asgeija asgeija added the backend label Oct 8, 2026
@asgeija asgeija added this to the Partial submission 2 milestone Oct 8, 2026
@asgeija asgeija requested a review from a team as a code owner October 8, 2026 10:04
@asgeija asgeija linked an issue Oct 8, 2026 that may be closed by this pull request
5 tasks
Copy link
Member

@jonatsm jonatsm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sighting.city is declared String! (never null), but in the database UFO_SIGHTINGS.LOCATION_ID is nullable. A sighting with no location has no city, so the resolver would return null for city.

I tested it with a fake resolver returning two sightings, one with city: null:

{"data":null,"errors":["Cannot return null for non-nullable field Sighting.city."]}

GraphQL handles a null in a field marked ! by making the field above it null, and repeats this upwards. Every level here is marked !: node: Sighting!, [SightingEdge!]! and SightingConnection!. So the null climbs all the way to the top, and the whole response becomes data: null, including totalCount and the 19 valid sightings. A single bad row would break an entire page of search results.

@asgeija
Copy link
Member Author

asgeija commented Oct 8, 2026

Sighting.city is declared String! (never null), but in the database UFO_SIGHTINGS.LOCATION_ID is nullable. A sighting with no location has no city, so the resolver would return null for city.

I tested it with a fake resolver returning two sightings, one with city: null:

{"data":null,"errors":["Cannot return null for non-nullable field Sighting.city."]}

GraphQL handles a null in a field marked ! by making the field above it null, and repeats this upwards. Every level here is marked !: node: Sighting!, [SightingEdge!]! and SightingConnection!. So the null climbs all the way to the top, and the whole response becomes data: null, including totalCount and the 19 valid sightings. A single bad row would break an entire page of search results.

I've pushed a change that fixes this

@thortve
Copy link
Member

thortve commented Oct 8, 2026

datetime is documented as UTC, but NUFORC times are local wall-clock times (schema.ts:5)
The importer, the resolvers and the frontend date formatting will all be built to follow this description. If it says UTC, US sightings will show up on the wrong day. Nothing will throw an error, so nobody will notice until the data looks off. Fix it now by documenting the field as a local time without a time zone (e.g. "2005-01-01T00:30:00", no Z). It's a one-line doc change today. Later, it means fixing the importer, the API and the frontend together

@asgeija
Copy link
Member Author

asgeija commented Oct 8, 2026

datetime is documented as UTC, but NUFORC times are local wall-clock times (schema.ts:5) The importer, the resolvers and the frontend date formatting will all be built to follow this description. If it says UTC, US sightings will show up on the wrong day. Nothing will throw an error, so nobody will notice until the data looks off. Fix it now by documenting the field as a local time without a time zone (e.g. "2005-01-01T00:30:00", no Z). It's a one-line doc change today. Later, it means fixing the importer, the API and the frontend together

You're right, I assumed it was UTC since the places are all over the world. Changed the description to local time
without a timezone.

@asgeija
Copy link
Member Author

asgeija commented Oct 8, 2026

@thortve @jonatsm is this good to merge now?

Copy link
Member

@jonatsm jonatsm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@jonatsm jonatsm merged commit 70fd10c into main Oct 8, 2026
1 check passed
@asgeija asgeija deleted the 30-define-the-graphql-schema branch October 12, 2026 10:55
Sign in to join this conversation on GitHub.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Define the GraphQL schema
3 participants